lib/codex-manager.ts, line 4078-4103 (link)

startup recovery prompt - no windows concurrency reasoning or retry guard

the runAuthLogin recovery prompt calls getActionableNamedBackupRestores, which in storage.ts fans out to Promise.all(backups.map(...assessNamedBackupRestore)). on windows, av tools can hold a read lock on .json files in ~/.codex/multi-auth/backups/. a concurrent read of multiple backup files will race those locks and can throw EBUSY or EPERM — silently swallowing the error and showing the user no restore prompt at all.

per org rule, every code change must explain the windows filesystem concurrency defense and reference the regression test that reproduces the race. neither is present here.

additionally, the backupLabel below leaks the raw backup file name (which could include account-derived path fragments) directly into the confirm() prompt string without scrubbing.

Rule Used: What: Every code change must explain how it defend... (source)

lib/codex-manager/settings-hub.ts, line 2949-2966 (link)

sync center apply - error message may leak token data and saveAccounts is unguarded

syncAccountStorageFromCodexCli can throw with an error whose .message comes from deep within token validation or oauth refresh. storing that raw message in statusDetail and rendering it in the sync center UI is a token leakage path — the same surface that rule 637a42e6 requires every patch to address.

additionally, saveAccounts here is called without any windows write-queue guard. if an av tool holds an EBUSY lock on the storage file at the moment apply fires, the write silently fails and the ui continues as if nothing happened.

Rule Used: What: Every code change must explain how it defend... (source)

lib/storage.ts, line 1281-1311 (link)

Promise.all over backup reads risks EBUSY on windows

Promise.all(backups.map((backup) => assess(backup.name, ...))) fires all backup file reads simultaneously. on windows, av tools serialize directory scans and can hold shared read locks on each .json file in the backups directory. firing several concurrent fs.readFile calls into the same directory raises EBUSY or EPERM on the losing reads.

the function has no retry shim and callers don't guard it. either serialize the reads sequentially or wrap each assess call with the same retry envelope used in withQueuedRetry for settings writes.

no vitest race regression test is present for this path.

Rule Used: What: Every code change must explain how it defend... (source)

lib/codex-manager.ts, line 4078-4103 (link)

Missing try-catch around backup assessment – login crash on Windows file lock

getActionableNamedBackupRestores does a Promise.all over every backup file in ~/.codex/multi-auth/backups/. if any individual assessment throws (e.g. EPERM/EBUSY from antivirus holding a file on Windows), the entire awaited call rejects and bubbles up unhandled through runAuthLogin, crashing the login flow rather than falling through to OAuth.

this is a high-probability Windows failure: the recovery prompt is gated on existingCount === 0, meaning it only fires on first-run or after a reset – exactly the moment a user is most likely to have a newly-placed backup file that an antivirus is still scanning.

wrap the assessment call in a try-catch so that any filesystem error is swallowed and the prompt is simply skipped:

let recoveryState: Awaited<ReturnType<typeof getActionableNamedBackupRestores>> | null = null;
try {
    recoveryState = await getActionableNamedBackupRestores({
        currentStorage: refreshedStorage,
    });
} catch {
    // filesystem error (e.g. Windows EPERM/EBUSY) – skip recovery prompt
    recoveryState = { assessments: [], totalBackups: 0 };
}
if (recoveryState.assessments.length > 0) {
    // ... existing prompt logic
}

lib/storage.ts, line 1298-1311 (link)

Promise.all has no per-backup error isolation – one bad file blocks all

Promise.all rejects on the first thrown assessment. on Windows, antivirus or another process can lock any individual backup file at any time. a single EBUSY/EPERM on one file fails the entire getActionableNamedBackupRestores call, making the result useless for the remaining valid backups.

use Promise.allSettled and filter to fulfilled results only:

const settled = await Promise.allSettled(
    backups.map((backup) => assess(backup.name, { currentStorage })),
);
const assessments = settled
    .filter((r): r is PromiseFulfilledResult<Awaited<ReturnType<typeof assessNamedBackupRestore>>> => r.status === "fulfilled")
    .map((r) => r.value);

then apply the existing actionable filter on assessments. this way one unreadable file doesn't block recovery for the rest.

lib/codex-cli/sync.ts, line 555-557 (link)

lastCodexCliSyncRun module-level state is overwritten by concurrent async operations

lastCodexCliSyncRun is a shared mutable module variable. if previewCodexCliSync and syncAccountStorageFromCodexCli are both awaited concurrently in the same process (possible if a background live-sync fires while the sync-center preview is refreshing), the last setLastCodexCliSyncRun call wins regardless of which operation actually finished last.

the returned getLastCodexCliSyncRun() snapshot might then reflect a preview run's outcome when the UI was expecting to see the apply outcome, or vice versa.

consider stamping each run with an incrementing sequence number and exposing both the latest preview run and the latest apply run separately, or at minimum document the last-write-wins semantic in the interface comment so callers know not to rely on ordering.

lib/codex-manager/settings-hub.ts, line 2957-2960 (link)

saveAccounts has no EBUSY/EPERM retry in the sync apply path

saveAccounts(synced.storage) is called here with no Windows-style retry guard. compare to withQueuedRetry used for every settings write in this same file. on windows, antivirus or another process holding the storage file will throw EBUSY/EPERM, the outer catch swallows it into preview.status = "error", and the sync result is silently lost. the user has to refresh and apply again.

the existing RETRYABLE_SETTINGS_WRITE_CODES set and withQueuedRetry already solve this pattern; the apply path should go through it or at least through the same enqueueSettingsWrite queue to avoid clobbering concurrent settings writes on the same path.

lib/live-account-sync.ts, line 3246-3248 (link)

Module-level singleton clobbered by multiple LiveAccountSync instances

publishSnapshot() overwrites lastLiveAccountSyncSnapshot unconditionally. if more than one LiveAccountSync instance is alive simultaneously (plugin mode + a test helper, or a second call to syncToPath without calling stop first), the older instance's state is lost on every reload/stop/error event.

the sync center reads getLastLiveAccountSyncSnapshot() to show live-watcher status; if a second instance is created and then stopped before the user opens the sync center, the display will show "idle" even though the original watcher is still running.

consider storing snapshots keyed by path, or at minimum assert in syncToPath that this.running === false before overwriting the singleton.

lib/codex-manager.ts, line 491-499 (link)

EACCES missing from Windows filesystem fallthrough whitelist

the catch block only swallows EPERM and EBUSY, but Windows also raises EACCES (access denied) when the backup directory has restrictive ACLs or is under a folder that antivirus has locked at the directory level. if that happens, getActionableNamedBackupRestores throws EACCES, the condition code !== "EPERM" && code !== "EBUSY" is true, and the error is re-thrown — crashing the login flow instead of silently falling through to OAuth.

the regression test added for EPERM/EBUSY should be extended with an EACCES case to lock in this behavior.

lib/codex-manager.ts, line 4383-4403 (link)

Transient Windows lock permanently suppresses recovery prompt

recoveryPromptAttempted = true is set on line 4383 before the try-catch. When a Windows filesystem lock (EBUSY/EACCES/EPERM) is caught, the flag is already true, so the recovery prompt is permanently suppressed for the rest of the session — even if the lock was transient (e.g., antivirus briefly holding a file). The only signal is a console.debug that users never see.

A user who hits a momentary AV lock on first login would silently bypass recovery and go straight to OAuth, losing access to their named backups until they explicitly navigate to Restore From Backup.

Consider moving recoveryPromptAttempted = true into the path where the assessment actually succeeds and a prompt is shown, or at minimum emit a visible warning (not just console.debug) when a filesystem lock causes a skip:

if (canPromptForRecovery) {
    let recoveryState: ...;
    try {
        recoveryState = await getActionableNamedBackupRestores({ currentStorage: refreshedStorage });
        recoveryPromptAttempted = true; // only committed after a successful read
    } catch (error) {
        const code = error instanceof Error && "code" in error ? String(error.code) : undefined;
        if (code !== "EPERM" && code !== "EBUSY" && code !== "EACCES") {
            throw error;
        }
        // filesystem lock – skip this attempt but allow retry on next loop iteration
        console.warn(`[recovery-prompt] backup assessment skipped (${code}); will retry next iteration`);
        recoveryState = { assessments: [], totalBackups: 0 };
    }
    ...